While computers are still used for their traditional processing purposes, advances in communication infrastructures and protocols have turned standard computing devices into valuable communication tools. Computers communicate with each other, and with other electronic devices, over networks ranging from local area networks (LANs) to wide reaching global area networks (GANs) such as the Internet. Other electronic devices have experienced similar transformations, such as mobile phones, personal digital assistants (PDAs), and the like. Today, these wireless devices are being used for a variety of different types of communication. For example, while the analog mobile phone was traditionally used for analog voice communications, the mobile phone of the present and future is a powerful communication tool capable of communicating voice, data, images, video, and other multimedia content. PDAs, once the portable calendaring and organizational tool, now often include network communication capabilities such as e-mail, Internet access, etc. With the integration of wireless and landline network infrastructures, information of all sorts can be conveniently communicated between wireless and landline terminals.
In carrying out such communications between devices, the programs, applications, application instances, and the like (hereinafter “applications”) operable on such devices often need to communicate with applications on other devices. For example, an application at the application layer may generate messages that are communicated to lower levels of the software architecture including, e.g., the transport layer, network layer, data link layer, and physical layer, where the encapsulated messages are transmitted over the network to other devices. Messages received at the receiving device move up the software architecture to ultimately provide the original message to an application on the receiving device.
To facilitate the communication of messages, message queues may be used. Generally, a message queue relates to the functionality that receives messages from an application and forwards them to a recipient application. The message queue serves as a temporary storage facility for traveling messages. Such message queues generally reside in the devices that are sending and receiving the messages, and alternatively may reside in an intermediary computing system on the network logically positioned between the sending and receiving devices.
The use of message queues removes many aspects of the message communication from the applications themselves. A message queue stores messages, such as when there is no connectivity between the communicating applications. Another benefit is the reliability, as the use of message queues provides safe and orderly delivery of messages. Thus, one benefit of utilizing message queues is that is obviates the need for application developers to develop, or even fully understand, the underlying functionality for performing these orderly transfers of messages to and from their applications.
When a message queue receives a message from the transport layer, it must know to which application instance the message is directed. It is not always enough to recognize the application type since the host may have several instances of the application software running at the same time. Moreover, the situation becomes more complicated where application instances are suspended, or terminated. Thus, the message must be passed to the correct application when it is activated or reactivated.
Where message queues are not used, this problem does not occur, since the application instance directly activates and uses the transport protocol instance. However, when a message queue is used, this association is lost. One solution is to introduce message queues at both ends so that it is possible to use a specific (and possibly proprietary) protocol or packet header to uniquely identify the communicating applications. For example, the sending message queue adds a proprietary message queue header that contains a unique identifier.
However, this approach limits the use of message queue only to those cases when both communication ends support the same kind of message queue. This leads to fragmentation, and is not desirable from the developer's point of view. In such a case, the developer must make different versions of the software or include support for cases where there is, and is not, a message queue at the other end.
Accordingly, it would be desirable to provide a manner in which a message queue may be deployed only at one side of the end-to-end communication channel. It would also be desirable to overcome the need to have (possibly proprietary) protocol and/or packet headers between the communicating ends for uniquely identifying the communicating peers. The present invention provides a solution to these and other problems of the prior art, and provides additional advantages over prior art message transactions implementing message queues.